As methods and devices for engaging in financial transactions have increased, old problems such as fraud and counterfeiting persist.
One of the primary sources of fraud, which is prevalent in the credit card industry is skimming. Skimming refers to the electronic copying of a card's magnetic stripe data to create counterfeit cards.
Skimming is predominantly a phenomenon afflicting magnetic stripe based transactions. This is because the magnetic stripe, which is placed on the back of a transaction card and stores a variety of data on three separate tracks, is a passive medium. In other words, the digital content of the magnetic stripe can be perfectly copied, without any difference between the copy and the original.
One of the primary means by which skimming can be prevented is for the consumer to closely monitor the whereabouts of his transaction card. This may allow the consumer to prevent the card from being swiped through inappropriate devices. However, as contactless cards evolve, the classic skimming problem comes along with it. In fact, in a wireless environment the opportunity to skim magnetic stripe data is more prevalent. In a wireless environment, a potential skimmer need not physically possess the card to be skimmed nor have access to any of the physical equipment (e.g. POS terminal, communication lines, etc.), which is required for skimming in a wire based environment. A skimmer can, without the knowledge of the consumer or merchant, intercept the wireless transaction and copy the data being transmitted from the card to POS terminal.
Some prior systems use an encrypted dynamic card verification value (dCVV) to authorize a transaction. At the front end, a portable consumer device generates the dCVV based on a counter that changes after every transaction. In some cases, the front end transmits the dCVV and the counter on Track data to the backend. The backend computer independently generates a second dCVV based on the transmitted counter. To verify the transaction, the backend matches the second dCVV to the dCVV received from the front end. If the values match, the transaction is considered authentic. If the values do not match, this may indicate that the transaction is fraudulent.
Although the above system works well, counters typically take up, at least, four or five characters of Track data since consumers could conceivably make thousands of transactions on a single portable consumer device. Track data is communicated from the portable consumer device to various other devices to authenticate the transaction. Due to the limited available space in the tracks, the number of characters in a counter data field may be limited, for example, to four characters. If the consumer conducts more than 9999 transactions, then the counter data field may not be able to accommodate counter values with more than four characters long. Thus, reducing the number of characters in Track data would be desirable.
Also, an unauthorized person could potentially intercept a counter value that is present in the Track data if it is in the clear and unencrypted. If the unauthorized person knows other information that is used to create a dCVV, the dCVV could theoretically be obtained by the unauthorized person and the unauthorized person could potentially conduct fraudulent transactions.
Embodiments of the disclosure address the above problems, and other problems, individually and collectively.